home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1480.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.7 KB  |  59 lines

  1. I've thought about this business of getting a WWW browser to execute
  2. a program and I've convinced that a new URL scheme is necessary
  3. for some uses.  In particular, you need it if you want to repeatedly
  4. run a program which outputs HTML (or MIME) and generally acts like
  5. a server.
  6.  
  7. An executable MIME content type is good for "one-shot" executions
  8. (like a "mail developers" link which runs a mailer), but it can't
  9. cover the more dynamic semi-server case.  Why?  Because you need
  10. a MIME document to back up each URL your server outputs that
  11. refers back to the server.  This is fine with an HTTP server, but
  12. for a browser-executed server it means having a file for every
  13. link which defeats the purpose.
  14.  
  15. A hack to the file: scheme is mostly OK except that it limits executable
  16. things to file: (no big deal with the MIME executable content type),
  17. is not particularly abstract (it points to a specific file) and leaves
  18. the relative URL semantics hanging.  Look at the HTML output of
  19. file:/bin/rn.html%/comp/sources/misc.  If it outputs the anchor
  20. <A HREF=/comp/binaries/mac>mac</A>, does that mean
  21. file:/comp/binaries/mac or file:/bin/rn.html%/comp/sources/mac?
  22. The writer of "rn.html" would certainly prefer the latter over
  23. having to constantly spit out full references, but the former is
  24. what should really happen.  Sure, we could pass in the full URL
  25. to rn.html so it knows the path, but that seems pretty messy.
  26.  
  27. So how about this:  an "exec:" scheme that looks like:
  28.  
  29.     exec://encoded-URL/opaque/stuff/like/other/URLs
  30.  
  31. Semantics: decode the "encoded-URL", grab it and execute it
  32. with the rest of the URL.  I used the  "//" notation so
  33. that executables can ouput "/" rooted URLs without having
  34. to know who they are, that is, rn.html can say "<A HREF=/comp/risks>".
  35. We can do the "encoded-URL" any way we like, but suppose that
  36. : -> ; and / -> \.  A full exec: URL might look like:
  37.  
  38.     exec://file;\bin\rn.html/comp/sources/misc
  39.  
  40. However, with the MIME executable content type, I'd expect that
  41. most exec: URLs would point to files, so file: would be the default.
  42. Additionally, the browser might have some notion of a PATH for
  43. exec: files (possibly as a first-level security mechanism), so the
  44. whole thing could be shortened to:
  45.  
  46.     exec://rn.html/comp/sources/misc
  47.  
  48. I fully realize that these URLs probably won't work between different
  49. sites.  I don't expect WWW servers to be sending you these any time
  50. soon (unless they're trying to delete all your files :-), but
  51. it's possible if some general agreement on the symbolic names
  52. happens.  For instance, it may become agreed that
  53. <A HREF=exec://mailer/mosaic-guys@ncsa>bug report</A> will
  54. fire up some kind of mail program.
  55.  
  56. While the file: with %/ hack is workable, I think this is better.
  57. What do you think?
  58.  
  59.